Modeless and Modalを読む
モードレスとモーダル
- ユーザーインターフェースを支配する最もハイレベルな2大思想
- ユーザーインターフェース
- 人とシステムのコミュニケーション様式
Syntax: CUI vs GUI
CUIとGUIの最も大きな違いは「操作のシンタックス」
- CUIは「動詞＋目的語」
- ことを優先
- GUIは「目的語＋動詞」
- ものを優先
GUIの核: Direct Manipulation（直接操作）
「間接的なメンタルモデル」をできるだけ排除し、現実の物理法則っぽくUIを表現する
- GUIの特徴
- グラフィカルな見た目（ただし本質はそこではない）
- 「目的語→動詞」のSyntax
- 直接操作の実現方法（『ユーザー・インターフェースの設計』 by Ben Shneiderman）
- 操作対象および動作の連続的な表示
- 複雑な構文ではなく、物理的動作やボタンによる操作
- 操作対象への影響が即座に見られる高速で逐次的かつ可逆的な操作
プログラミングという作業がどういうものか何のイメージも持っていなかった僕にとって、そのイベントドリブン（もちろん当時はそんな言葉は知りませんでしたが）な世界は、いったいどうやってできているのかとても不思議でした。膨大な反応のバリエーションがあらかじめ裏に用意されているのだとは（そんなめんどくさいことをする人がこの世にいるとは）、思いもよらなかったのです。
ポインタと「いつでも始められる」感覚（モードレス感の源泉）
マウスポインタの重要性
- カーソル位置とは独立して任意座標に移動できる
- 意味を持つのは クリック という明示ジェスチャの時だけ
- 気が変われば何もしなくてよい
- 意識の所在はカーソルではなく、むしろマウスポインタ側にある
「いつでも好きなことを始められる」
- 「今は自分は何をすべき」という決まりがなく
- 「これから自分が何をするか」だけがある
速い人＝ショートカットで「Syntaxの段差」を消している
- 作業が速い人に驚愕した話
その人の左手は、常に親指をコマンドキーに乗せていて、それがホームポジションになっていました。そしてキーボードショートカットを多用しているのです。右手は常にマウスを持っていてアクセラレーションをうまく使って最小限の動きでターゲットの座標にポインターを移動します
- GUIの「目的語→動詞」のうち 動詞 を「手が覚えたショートカット」で実行できる
- 操作が「段階的」でなくなり、手続きを計画する認知負荷が下がる
- 対象物と一体化した感覚＝フロー が起きやすい
- そもそもGUIには「目的語」と「動詞」が一体化したジェスチャが多い
- ダブルクリック = 対象選択＋開く
- ドラッグ＆ドロップ = 対象選択＋移動
- 端へドラッグで自動スクロール = 選択＋移動＋スクロールの合成
これらのジェスチャが自然に実装されていて、思い通りの振る舞いをしてくれる時、ユーザーは手続きとしてのリニアな操作ステップを意識しなくてもよくなります。その時 GUI は最も強力なツールとなるのです。
ボタン批判（直接操作の「挫折」としてのボタン）
ボタンが全然ないような画面の方が良い。ボタンは、道具としての機械が複雑化してきた過程において、直接操作の実現を放棄した挫折のUI。
- ボタンはGUIのメタファーとして優秀
- 操作対象として目に見える、現実世界の比喩が強い
- ただしボタンの入力は 0/1の「1」（極端にデジタル）
- 無限段階のアナログ操作から最も遠い
- ボタンが便利な理由
- ノイズのない単純操作で複雑処理を起動できる
- 内部の複雑さをユーザーから完全に隠せる
- しかし本質的には「バッチ処理の開始合図」＝間接操作
- 直接押せる意味では直接操作だが
- ボタンは「操作対象」ではなく、Syntax上の動詞の選択肢にすぎない
- 動詞指定はインタラクションのフロー感をスポイルしやすい
- 意識が「対象物の状態」から「コマンド選択」へ移るため
Modelessness（モードレス）とは何か？
アプリケーションはできるだけモードが無い方が良い
- モードがない = ユーザーが好きな時に好きなことができる
- モードは行動を制限し、「一つの作業を終えるまで次へ行けない」を作る
- モードが減るほどユーザーはコンピュータをコントロールできる
Object-Oriented（オブジェクト指向）と「文脈」
subject vs object
「事よりも物に着目する」
- subject（サブジェクト）
- 文脈的 / 暗示的 / リンク / 事
- object（オブジェクト）
- 宣言的 / 明示的 / ノード / 物
部品と文脈
- 共通部品は使い回す
- 一定の部品集合で全体を構成
- 部品は文脈に依存せず存在できる
- 部品は部品によって呼び出される
- 文脈は「呼び出し方」で決まり、文脈に応じて部品の状態が変わる
「文脈をユーザーに解放する」
- システムは機能を体現するだけで、使い方を指示すべきではない
- 道具が役に立たないのは「道具が状況に適していない」のであって
- ユーザーの使い方が悪いのではない
エンジニアリング比喩（if地獄 vs オブジェクトの独立）
- if を重ねた条件分岐で処理を変えると簡単にぐちゃぐちゃになる
- あらゆる状況を想定してテストしないといけない
- コツ
- オブジェクト同士が互いの（あるいはユーザーの）文脈に できるだけ無関心 でいられるようにする
- GUIでは状況は無限にあるから
タスクベースUI批判（＝「動詞→目的語」に戻ってしまう）
エンジニアが作ったモックアップのポンチ絵を見て、僕は強烈な違和感を覚えました。このシステムの基本要件は、画像（メタ）データの照会、追加、変更、削除、他システムへの送信といったものだったのですが、モックアップでは、初期画面において、「照会」「追加」「変更」「削除」「送信」というボタンがそのまま並んでいるのです。そして例えば「照会」ボタンを押すと、画像データのサムネール一覧が検索機能などと共に表示され、そのうちひとつを選ぶと画像の内容が表示されます。初期画面に戻って今度は「変更」ボタンを押すと、同じように画像のサムネールが表示され、ひとつを選ぶとメタデータ変更フォームが表示されます。いずれも同じ対象データを同じように一覧表示するのですが、そこでできることは初期画面で選んだ項目（タスク）に依存していて、別なことをやろうとしたら一度初期画面に戻らなければならないのです。
- s ものすごくタスクベースUIだ
- 対象データの一覧表示は同じでも、できることが「最初に選んだタスク」に縛られる
- 別のことをやるには「戻る」が必要＝モードの強制
それでもモードが必要になるパターン
- 「動詞→目的語」の壁を破れず、モードを作らざるを得ないとき
- タスクによって処理対象オブジェクト集合が異なる
- タスク選択が「アプリ選択」に近くなる
- タスクごとに提示すべきプロパティ/メソッドが大きく異なる
- 先にオブジェクトを出すと情報過多でUIが破綻
- 対象オブジェクトが存在しない・1つで選択不要
- 引数入力がタスクの大部分（例：券売機）
- 創造的作業を禁止し、順序を限定したい（ウィザード）
- 整合性/セキュリティ上トランザクションを一元化したい
- モード退出タイミング＝トランザクション確定が望ましい
- タスクによって処理対象オブジェクト集合が異なる
これを打破するためには、業務手続き自体をもっと自由にするか（これは企業ガバナンス的にあり得ない方向性ですが）、もしくは、業務アプリケーションの役割を「業務手続きのオンライン化」から「業務のオンライン化」に変えていく必要があるのではないかと思います。
比喩: 自動車（OO） vs 電車（タスク）
GUIは本来自動車である
- オブジェクト指向UIとタスク指向UIの対比
- 自動車
- ルートも寄り道も変更も自由（改善もできる）
- ただし迷子リスク（ゴールが自明でないと詰む）
- 電車
- 目的地を最初に選べば確実に着く
- 途中変更や工夫はできない
- 自動車
OOUIの要件
- 良いユーザーインターフェースとは OOUI
- オブジェクトとそれらのビューの協調で構成
- タスク入出力より オブジェクト入出力 を重視
- ユーザーは自分なりの方法でタスク遂行・改善できる
- 限定的オブジェクトを複数タスクで使い回す
- 状態がリアルタイムに視覚フィードバックされる
- 1オブジェクトは複数ビューを持てる
- 直接操作・可逆的（Undo前提）
- 全オブジェクトが常にアクティブ
- 内部仕組みを隠匿
- 目的語 → 動詞
- ユーザーが見るのはアプリではなく オブジェクト
- オブジェクトが役割を体現する
オブジェクト指向UIとかタスク指向UIというのは、方式として機械的に設計できるようなものではなく、もっと感覚的なというか、思想的なものなのだと思います。ある機能をどちらのシンタックスで実現するかは、自由に選択できるわけではなく、そのシステムの基本的なコンセプトから必然的に決まってくるものです。だからどちらが優れているということはないのですが、コンセプトが曖昧だったりインタラクションの一貫性が意識されていなかったりすると、両者がコンフリクトを起こして、不合理でちぐはぐな操作性になってしまうのです。
